Hit this same limitation independently: production Flyway migrations using the SQL-standard keyword form on a user-defined type (ALTER TABLE t ADD COLUMN c currency ARRAY). Tested this branch against those migrations plus adjacent shapes (INTEGER ARRAY, TEXT ARRAY[4], NUMERIC(10,2) ARRAY, public.currency ARRAY, INT ARRAY DEFAULT ARRAY[]::INT[]) - all parse and round-trip correctly. Two suggestions:

1. Enable it for GenericDialect. The README asks for dialect-specific syntax to be accepted by both the relevant dialect and GenericDialect, and the bracket form's supports_array_typedef_with_brackets is already enabled for generic, so the keyword form should follow:

 // src/dialect/generic.rs
+    fn supports_array_typedef_with_keyword(&self) -> bool {
+        true
+    }

2. Widen the tests. The current tests cover built-in element types in CREATE TABLE and CAST. These cases exercise different paths (custom and schema-qualified type names, ALTER TABLE, parenthesized typmods, and the suffix-vs-constructor ambiguity) and are worth pinning:

pg_and_generic().verified_stmt("CREATE TABLE t (c currency ARRAY)");
pg_and_generic().verified_stmt("CREATE TABLE t (c public.currency ARRAY)");
pg_and_generic().verified_stmt("ALTER TABLE t ADD COLUMN c currency ARRAY");
pg_and_generic().verified_stmt("CREATE TABLE t (c NUMERIC(10,2) ARRAY)");
pg_and_generic().verified_stmt("CREATE TABLE t (c INT ARRAY DEFAULT ARRAY[]::INT[])");

(pg() instead of pg_and_generic() if you'd rather keep the generic change separate.)

Can send both as a patch against your branch if that's easier.

@iffyio could you check this out when you have time?